Synchronization of offline instances

ABSTRACT

An enterprise system which facilitates synchronization of offline data. Offline data created during an offline session or sessions (collectively an offline session) prior to synchronization is assigned a temporary key. Changes of offline data created during an offline session is assigned the temporary key of the data to which the change is associated. The temporary key is mapped to a new created backend key and stored in a mapping table. Using the mapping table, temporary keys associated with the changes are swapped with backend keys which the temporary keys are mapped. This maintains data persistency of newly created and change data during an offline session.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.14/977,558, filed Dec. 21, 2015, the contents of which is incorporatedherein by reference in its entirety.

TECHNICAL FIELD

The present disclosure relates to computer systems, and morespecifically, to a framework for facilitating update of offline data.

BACKGROUND

Enterprise systems contain data used by numerous users. Generally,enterprise data is created or manipulated on a client device andsynchronized with a server. For example, new data can be created or newrows can be added to lists like items of a sales order. When data issynchronized with the backend server, a backend key is generated andassociated with the data.

However, a problem with conventional enterprise systems exists when datais created offline and prior to synchronizing with the server, it issubsequently changed. The creation and subsequent change results indifferent instances of data. However, since the created data has notbeen synchronized, no backend key is associated with it. When thecreated data and change data are synchronized, the server generates twodifferent backend keys, one for the original data and another for thechange data. This unfortunately results in non-persistent data.

From the foregoing discussion, it is desirable to provide an enterprisesystem which avoids non-persistent data.

SUMMARY

A framework for providing an enterprise system which facilitatessynchronization of offline data is described herein. In accordance withone aspect, a computer implemented method for uploading offline data isdisclosed. The method includes generating offline change data using aclient runtime of a frontend sub-system of an enterprise data systemresiding on an end user device, wherein the offline change datacomprises a change data type. The change data type is selected from anewly created base document, a change to the newly created basedocument, and a change to a previously synchronized base document. Themethod also includes processing the offline change data. The offlinechange data includes determining the change data type, and if the changedata type includes the newly created base document, the processinggenerates a new unique client key associated with the newly created basedocument. If the change data type includes the change to the newlycreated base document, associating the new client key of the newlycreated base document to the change of the newly created base document.If the change data type includes the previously synchronized basedocument, associated a backend key of the previously synchronized basedocument to the change of the previously synchronized base document.

The method further includes storing the change data and associated keyas an entry in a synchronization queue. The synchronization queue issynchronized with a backend sub-system of the enterprise data systemresiding on a server when the end user device is online. Synchronizingwith the backend sub-system includes processing the synchronizationqueue, wherein if the change data is the newly created base document,the processing includes generating a new backend key, the new backendkey is associated with the newly created base document, and mapping thenew backend key to the client key associated with the newly created basedocument to form a mapped key pair in a key mapping table. If the changedata type is the change of the newly created base document or thepreviously synchronized base document, the processing includes assigningthe backend key associated with the newly created base document or thepreviously synchronized base document with which the change data isassociated. The method further includes storing the change data in thebackend sub-system.

In another aspect, a computer implemented method for uploading offlinedata is disclosed. The method includes generating offline change datausing a client runtime of a frontend sub-system of an enterprise datasystem residing on an end user device, wherein the offline change datacomprises a change data type. The change data type is selected from anewly created base document, a change to the newly created basedocument, and a change to a previously synchronized base document. Themethod also includes processing the offline change data. The offlinechange data includes determining the change data type, and if the changedata type includes the newly created base document, the processinggenerates a new unique client key associated with the newly created basedocument. If the change data type includes the change to the newlycreated base document, associating the new client key of the newlycreated base document to the change of the newly created base document.If the change data type includes the previously synchronized basedocument, associated a backend key of the previously synchronized basedocument to the change of the previously synchronized base document. Themethod further includes storing the change data and associated key as anentry in a synchronization queue.

In yet another aspect, an enterprise system which includes a frontendsub-system residing on an end user device is disclosed. The frontendsub-system facilitates synchronization of offline change data with abackend sub-system residing on a server, wherein the offline change datacomprises a change data type. The change data type is selected from anewly created base document, a change to the newly created basedocument, and a change to a previously synchronized base document. Thefrontend sub-system includes a client key generator unit for generatinga client key when the offline change data includes the newly createdbase document. The client key is associated with the newly created basedocument. The frontend sub-system further includes a synchronizationqueue containing entries with offline change data and associated keys.The associated key is a client key generated by the client key generatorwhen the offline change data is the newly created base document. Theassociated key is a client key associated with the newly created basedocument when the offline change data is the change to the newly createdbase document. A backend key of the previously synchronized basedocument is associated to the change of the previously synchronized basedocument.

With these and other advantages and features that will becomehereinafter apparent, further information may be obtained by referenceto the following detailed description and appended claims, and to thefigures attached hereto.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated in the accompanying figures, in whichlike reference numerals designate like parts, and wherein:

FIG. 1 shows a simplified diagram of an exemplary enterprise system;

FIG. 2 shows the exemplary enterprise system in greater detail;

FIG. 3 shows an embodiment of a frontend of an update process flow; and

FIG. 4 shows an embodiment of a backend of the update process flow.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, specificnumbers, materials and configurations are set forth in order to providea thorough understanding of the present frameworks and methods and inorder to meet statutory written description, enablement, and best-moderequirements. However, it will be apparent to one skilled in the artthat the present frameworks and methods may be practiced without thespecific exemplary details. In other instances, well-known features areomitted or simplified to clarify the description of the exemplaryimplementations of the present framework and methods, and to therebybetter explain the present framework and methods. Furthermore, for easeof understanding, certain method steps are delineated as separate steps;however, these separately delineated steps should not be construed asnecessarily order dependent in their performance.

A framework is provided for updating data for an enterprise system. Anenterprise system includes numerous users which can be offline (notconnected) or online (connected). The framework, in particular,facilitates synchronization of offline data with the enterprise systemwhen a user is online.

FIG. 1 shows a simplified diagram of an exemplary environment 100. Theenvironment 100, for example, includes a server 140 and an end userdevice 130 interconnected to a communication network 110. Theenvironment may include other components.

A server may include one or more computers or servers. A computerincludes a memory and a processor. Various types of computers may beemployed for the server. For example, the computer may be a mainframe, aworkstation as well as other types of processing devices. The memory ofa computer may include any memory or database module. The memory may bevolatile or non-volatile types of non-transitory computer-readable mediasuch as magnetic media, optical media, random access memory (RAM),read-only memory (ROM), removable media, or any other suitable local orremote memory component. The computers or servers are connected througha communication network such as internet, intranet, local area network(LAN), wide area network (WAN) or a combination thereof. The servers,for example, are part of the same private network. The servers may belocated in single or multiple locations.

As for the user device, it may be any local computing device with, forexample, a local memory and a processor. The memory may be volatile ornon-volatile types of non-transitory computer-readable media such asmagnetic media, optical media, RAM, ROM, removable media, or any othersuitable local or remote memory component. As shown, the end user deviceincludes a mobile device, such as a smart phone device. Other types ofmobile devices may also serve as an end user device. For example, theend user mobile device may be a laptop personal computer (PC), a tabletPC, tabs as well as other types of mobile devices. The end user devicemay also be a non-mobile device, such as a workstation or desktop PC.Illustratively, the environment includes one end user device. It is tobe understood, however, that the environment may include numerous enduser devices connected to the communication network which accesses theserver. The end user devices may be any type or combination of types ofend user devices. For example, the end user devices may include mobileand non-mobile devices.

As discussed, the various components of the network are connectedthrough the communication network. For example, components of thenetwork may be connected by internet. Other types of networks or networkconnections may also be useful. For example, the network connections mayinclude a WIFI or a 3G/4G/LTE connection. In some cases, the network maybe a cloud. A user may connect to the server using the user device. Theuser device may be referred to as the client or frontend side while theinformation layout generation system may be referred to as the server orbackend side. Other types of configurations may also be useful.

In one embodiment, the environment may include an enterprise system 150.In one embodiment, the enterprise system may include an enterpriseresource planning (ERP) application. The enterprise system may includeother business-oriented tools which serve various functions. Suchfunctions may include accounting, business intelligence, processmanagement, content management, customer relationship management,resource planning, asset management, supply chain management as well asother functions. For example, the enterprise system may include acollection of software applications which serve various needs orfunctions of an enterprise.

In one embodiment, the enterprise system is configured as a distributedsystem. For example, the enterprise system is configured with aclient-server architecture. For example, the enterprise system includesa server-side or backend sub-system 170 residing on a server 140 and aclient-side or frontend sub-system 160 residing on an end user device130.

The enterprise system, when invoked by a user, may be used to generatedata. The user may also manipulate or change existing data. Theenterprise system may be used by a plurality of users. Users may beassigned an account. A user may access the backend or server-side byinitiating and logging in to the enterprise system through the frontendsub-system or client-side when connected to the network (online).Logging in may be automatically or manually performed by the frontendsub-system. For example, a user may pre-set the frontend sub-system withlogin information or, alternatively, may manually enter the logininformation. Other techniques for accessing the backend sub-system mayalso be useful.

A user may generate data while offline. For example, a user may generateor change data for the enterprise system when not connected to anetwork. In such a case, the data is located in the frontend andsynchronized with the backend when the user is online or connected tothe backend through the communication network. On the other hand, whenonline, the generated or change data is saved in both the frontend andbackend sub-systems. For example, a user may initiate saving ofgenerated or change data by selecting an enter button or a save button.Other techniques for saving online generated or change data may also beuseful.

The enterprise system may include objects, such as business objects.Objects, for example, are data in the enterprise system. Objects canrepresent various types of data. For example, objects may includeaccounts (customers), contacts, opportunities sales orders, quotes,activities (e.g., appointments, emails, or phone calls), and servicerequests. Other types of data may also be useful. Objects may also bemaster data instances, such as a territory, an employee or anorganizational unit. Other types of objects may also be useful. Objectsmay be created and subsequently changed. The various types of objectsmay be collectively referred to as documents. The creation and changingof objects or documents may be performed either offline or online.

As discussed, data or documents created or changed offline (offlinedocuments) are synchronized when the user is online. For example,offline documents created by the frontend sub-system are synchronizedwith the backend sub-system of the enterprise system when the user isonline. A document may be in an image format. Other types of documentformats may also be useful. Synchronization may be triggered by theuser, such as by manually pressing a synchronization button, orautomatically once online connectivity is available.

FIG. 2 shows an exemplary embodiment of an enterprise system 150. Theenterprise includes frontend and backend sub-systems 160 and 170. Thefrontend sub-system resides in an end user device and the backendsubsystem resides in a server.

The frontend sub-system, as shown, includes a client runtime module 221and a client local database module 231. The client runtime moduleincludes a client key generator unit 223. The client local databasemodule includes a frontend data unit 233 and a synchronization queueunit 235. Providing the frontend sub-system with other modules and unitsmay also be useful.

The client runtime module provides for displaying data to the user,handling frontend logic (including user changes or events), andcommunicating with the backend sub-system and (in an offline case) withthe local database. For example, the runtime module generates or changesdata, such as objects or documents. In one embodiment, the runtimemodule is used to generate data and change data. When offline, new datacan be generated and subsequently changed during the same offlinesession. Existing data may also be changed offline. When online, newdata may be generated and saved in the frontend and backend sub-systems.Existing data may also be changed.

In one embodiment, the client runtime module includes a client key oridentifier (ID) generator unit 223. Although the client key unit isshown as part of the runtime module, it is understood that it can be aseparate module which interacts with the runtime module. The client keygenerator unit generates a client or temporary key for a newly createdoffline document. For example, each newly created offline document willhave its respective unique temporary key or identifier. The temporarykey may be a temporary key set having first and second temporary keys.In one embodiment, a key set includes a human readable temporary key anda non-human readable temporary key. The human readable key may be aunique number, such as 005 while the non-readable key may be a technicalkey, such as a universally unique identifier (UUID).

Newly created documents, such as objects, are assigned or identified bythe temporary key. A temporary key is assigned to all newly createddocuments by the client key generator, whether created offline oronline. Changes may be made to a document. Changes include a change to abase document or even to another change of a change to a base document.Changes also include the use of the data of the base document or achange to a base document. For example, a new contact is created. Thecontact is used in a new appointment. The appointment which uses thedata of the contact is considered a change of the contact. A change hasthe same key as the base document for which the change is made.

In an offline scenario, a document may be a newly created document (basedocument) during an offline session. Prior to synchronizing with thebackend sub-system, a change is made to the base document. The changemay be made during the same or a different offline session so long as nosynchronization with the backend sub-system is performed between thedifferent offline sessions. The offline sessions without synchronizationmay be collectively referred to as one offline session. The change willhave the same temporary key with the base document. For example, a usercreates a new offline document A1. The key generator generates atemporary key K1 for document A1. Prior to synchronizing with thebackend sub-system (e.g., during the same offline session or a differentoffline session), the user makes a change to document A1. As discussed,a change to document A1 includes the use of data of document A1. Thechange of document A1 is associated with the temporary key K1.

In an online scenario, the newly created or base document will beassigned a backend key. For example, a backend key is swapped with thetemporary key. The change will have the same backend key as the basedocument. For example, a user creates a new offline document A1. The keygenerator generates a temporary key K1 for document A1. Document A1 issaved to the backend sub-system and a backend key is assigned to it. Asubsequent change to document A1, whether offline or online, will havethe same backend key as document A1.

The client local database unit, for example, is a memory storageresiding on the end user device. In one embodiment, the client localdatabase unit includes a data unit 233 and a synchronization queue 235.The data unit includes data of the user.

As for the synchronization queue, it contains entries 237 which includechange data created on the user device while offline and an associatedkey. For example, it contains documents which are to be synchronizedwith the backend sub-system when connectivity to the backend sub-systemis available (e.g., online). Change data may include creation of newdocuments, changes to newly created documents prior to synchronizationwith the backend sub-system as well as changes to existing documentspreviously synchronized with the backend sub-system. A change may alsoinclude a change to a change of a base document. A change also includesthe use of data of a base document or a change to a base document. Forexample, a new contact is created while offline. While still offline,the contact is used in a new appointment. The appointment which uses thedata of the new contact is considered a change of the newly createdcontact.

A document of a change made to a base document or another change, in oneembodiment, contains only the change made. The documents may be in animage format. Providing the documents in other formats may also beuseful. Each document may be an entry in the synchronization queue. Theentries may be listed in a first-in-first-out (FIFO) order. Otherordering of the entries may also be useful. The list, for example,includes data changes and keys. For a base document and its changesprior to synchronization, they will have the same client key. As achange to a previously synchronized base document, it will maintain thesame backend key of the base document assigned by the backendsub-system.

As for the backend sub-system, it includes a processor module 251 and abackend local database 261. The processor module, in one embodiment,includes a logic unit 253, a backend key generator unit 255, a mapperunit 257 and an upload processing unit 259. The backend local database,in one embodiment, includes a backend data unit 263, a key mapping tableunit 265 and an inbound queue unit 267. Providing the backend sub-systemwith other modules and units may also be useful. Although the units areshown as separate units, they may be integrated or combined with one ormore other units.

The various units of the processor module process the contents orentries of the inbound queue of the backend local database module. Whenthe end user device is online, the contents of the synchronization queueare synchronized to the inbound queue. In one embodiment, the uploadprocessing unit processes the contents of the inbound queue unit. Theupload processing unit may process the entries one at a time insequence. For example, the upload processing unit processes the entrieson a FIFO basis. Processing the entries based on other sequences mayalso be useful.

The logic unit processes the various entries in the synchronizationqueue. Processing by the logic unit includes generating enterprise datafor the entries. The logic unit may process the entries one at a time insequence. For example, the logic unit processes the entries on a FIFObasis. Processing the entries based on other sequences may also beuseful. The logic unit also processes online data to generate enterprisedata.

The backend key generator generates unique backend keys for new objectsor documents. The backend keys may be key sets, with a key set havinghuman and non-human readable keys. A newly created offline documenthaving a temporary key will be provided with a backend key by thebackend key generator. As such, all unique documents have respectiveunique backend keys. Unique documents exclude changes to documents. Forexample, changes to a unique document become part of the unique documentand maintains the same backend key.

The mapper unit maps backend keys for documents with temporary keys. Forexample, documents with client keys will have newly created backend keysmapped to the client keys. To illustrate, assume that thesynchronization queue unit includes 2 newly created offline documents A1and B1. Document A1 may be a first contact and document B1 may be asecond contact. In such a case, the client key generator generates atemporary key K1 for document A1 and a temporary key K2 for the documentB1. Subsequently during the same offline session, a change is made todocument A1. For example, the contact of A1 is used in a newappointment. Temporary key K1 is also associated to the appointment withthe contact of document A1 (e.g., change of document A1). The change issaved in the local database on the user device and loaded in thesynchronization queue as a new entry with key K1. The backend keygenerator will generate a backend key BK1 for A1 and a backend key BK2for B1. The mapper unit maps BK1 to K1 and BK2 to K2. As for theappointment which is a change of document A1, it will be assigned BK1.

The backend local database module includes memory for storinginformation. The database module may include any type of database. Forexample, the database may be a relational database or Structured QueryLanguage (SQL)-based database. In one embodiment, the database includesin-memory, such as SAP HANA database from SAP SE. Other types ofdatabases may also be useful.

The backend data unit of the backend module contains data of the user.For example, data of the user includes all data prior tosynchronization. As discussed, the enterprise system is shared by manyusers. The data of all the users of the enterprise system is containedin the backend data unit. Other types of data may also be contained inthe backend data unit. For example, the backend data unit may containother data needed to run the system.

As for the key mapping table unit, it contains a mapping of thetemporary and backend keys. For example, the mapping table unit containsthe mapping generated by the mapping unit. The mapping generated by themapper unit is stored in the mapping table unit in the backend localdatabase module. The mapping table may include entries which map aclient key to a backend key.

FIG. 3 shows an embodiment of a process 300 for offline generation ofdata for the enterprise system. For example, the process is performed bythe frontend sub-system residing on the end user device. At step 310,offline enterprise data is used or generated by the user. For example,the user may employ the runtime module to generate data. The data, sincethe user is offline, may be considered as a data change. A data changemay include, for example, a new document, a change to a newunsynchronized document or a change to an existing document.

At step 320, the process determines if the data change or document is anewly created document or not. If the change is a newly createddocument, the process proceeds to step 330. An indication that thechange is a newly created document is the lack of a key. For example, anewly created document will not have any keys associated with it at thetime of creation. At step 330, the process generates a client ortemporary key for the newly created document. For example, the clientkey generator generates a client key for the newly created document. Inone embodiment, the temporary key may be a key set including first andsecond keys. The keys, for example, include a human readable and anon-human readable key. The process continues to step 350.

On the other hand, if the document is not a newly created document, theprocess proceeds to step 340. A document which is not new newly createddocument has a key associated with it. For example, if the data changeis a change to an existing document which has been synchronized with thebackend sub-system, it will have a backend key associated with it. Onthe other hand, if the data change is a change to an unsynchronizeddocument with the backend sub-system, it will have a client or temporarykey associated with it. At step 340, the process obtains the key fromthe change of the document. The process continues to step 350.

At step 350, the document is stored in the user local database. Theprocess continues to step 360 where the document and associated key isloaded into the synchronization queue. All documents will have either aclient key or a backend key, depending on the type of data change. Theprocess terminates at step 370.

The process, as discussed, is initiated whenever a user changes data.For example, the process is initiated when the user creates a newdocument, changes a newly created document or changes a previouslysynchronized base document.

FIG. 4 shows an embodiment of a process 400 for uploading of datacreated offline. For example, the process is performed by the backendsub-system residing on the server. At step 410, the process isinitialized for uploading. For example, when the end user device isonline, the uploading process is initialized. Uploading may beautomatically performed when the end user device is online or when theuser initiates the process when online. Initialization includes settingcounter x to 1.

At step 420, the contents of the synchronization queue is copied to theinbound queue. For example, the inbound queue unit of the backenddatabase module is synchronized with the synchronization queue of theclient runtime unit on the frontend sub-system. At step 430, the entriesin the inbound queue are processed. For example, the uploader processesthe entries in the inbound queue. In one embodiment, the entries ordocument of the inbound queue are processed one at a time. For example,the i^(th) document of the inbound queue is processed.

Processing the document utilizes the logic unit of the processor unit ofthe backend sub-system. The processing determines if the document is anewly created document or not at step 440. For example, if the documentis a newly created document, the process proceeds to step 450. At step450, the backend key is generated for the newly created document. Forexample, the backend key generator generates a backend key for the newlycreated document. In one embodiment, the backend key may be a backendkey pair with a human readable key and a non-human readable key. Themapper maps the backend key to the temporary key at step 460 and storesthe pair of mapped keys in the mapping table. For example, the mappedkeys are stored as an entry table in a mapping table in the backenddatabase module. The process continues to step 470.

On the other hand, if the document is not a newly created document, theprocess proceeds to step 445. At step 445, the process determines ifthis is a change of a newly created document within the same offlinesession. A change to a newly created document has a temporary or clientkey assigned to it. The temporary key of the change is the same as thatof the newly created document. The change, for example, includes the useof the data of the newly created document. If the document is not anewly created document and has a temporary key, the process proceeds tostep 455.

At step 455, the process extracts the temporary key of the changeddocument. The process calls the mapper at step 460. The mapper, forexample, checks the mapping table and exchanges the temporary key withthe backend key that is mapped to it. The process continues to step 470.On the other hand, if the document is a change of an existingsynchronized document, it already has a backend key associated with it.As such, the process continues to step 470.

At step 470, the process uploads the data change in the data unit of thebackend database. The document is uploaded based on the backend key. Forexample, an image of the document is added into the backend database.The process marks the entry in the inbound queue as processed at step475. The process continues to step 480 to determine if there are moreentries in the inbound queue to process. For example, if x is less thanor equal to the last document of the inbound queue, the process proceedsto step 485 where x is incremented by 1. The process then returns tostep 430 and repeats until all entries have been processed. For example,if x is greater than the last document, the process terminates at step490.

As for the frontend sub-system, it may be synchronized as well. Forexample, the key pairs are exchanged. New backend keys are exchangedwith the corresponding client keys in the frontend sub-system. In someembodiments, documents with the new backend keys may be updated in thefrontend sub-system. This may include deleting the document with theclient key in the client database and replacing it with the documentwith the new backend key. Other techniques for updating the frontendsub-system or client database may also be useful.

As described, the various modules of the enterprise system may beembodied as an enterprise application. For example, the various modulesmay be embodied as a software application. The source code or codes ofthe application may be compiled to create an executable code. The codes,for example, may be stored in a storage medium such as one or morestorage disks. Other types of storage mediums may also be useful.

Although the one or more above-described implementations have beendescribed in language specific to structural features and/ormethodological steps, it is to be understood that other implementationsmay be practiced without the specific features or steps described.Rather, the specific features and steps are disclosed as preferred formsof one or more implementations.

The invention claimed is:
 1. A computer implemented method forsynchronizing data comprising: receiving, by an inbound queue at aback-end sub-system over a communications network, offline change dataoriginating as entries in synchronization queues on a plurality ofclient-side subsystems, the offline change data being generated at theclient-side subsystems when the client-side subsystems are not connectedto the back-end sub-system over the communications network, wherein theoffline change data represents changes that have not been synchronizedwith the back-end system, and wherein at least one of the entriesreflects creation of a new base document, at least one of the entriesreflects a change to the new base document, and at least one of theentries reflects a change to a previously synchronized based document,wherein for the respective synchronization queues, the first entry isthe earliest offline change data and the last entry is the latestoffline change data; and synchronizing, by the back-end sub-system, theentries in the synchronization queues until all such entries areprocessed, wherein the synchronizing comprises: upon determining thatthe entry corresponds to creation of a new base document, generating anew backend key associated with the new base document, mapping the newbackend key to a client key generated at the corresponding client-sidesubsystem and associated with the new base document to form a mapped keypair in a key mapping table, and storing change data specified by theentry in the back-end sub-system in association with the new backendkey; upon determining that the entry corresponds to a change to the newbase document, identifying, using the client key corresponding to thenew base document, the new backend key generated during thesynchronizing using the key mapping table, and storing change dataspecified by the entry in the back-end sub-system in association withthe new backend key, and upon determining that the entry corresponds toa change to a previously synchronized base document associated with apre-existing backend key, storing change data specified by the entry inthe backend sub-system in association with the pre-existing backend key.2. The method of claim 1, wherein the entries are sequentiallyprocessed.
 3. The method of claim 2, wherein the entries are processedon a first in first out (FIFO) basis.
 4. The method of claim 1, whereinthe synchronization queues have x number of entries for generating xnumber of change data while offline without synchronizing with thebackend sub-system, and wherein the x number of entries being stored inthe synchronization queue is based on a time when the change data isgenerated.
 5. A system comprising: at least one programmable dataprocessor; and memory storing instructions which, when executed by theat least one programmable data processor, result in operationscomprising: receiving, by an inbound queue at a back-end sub-system overa communications network, offline change data originating as entries insynchronization queues on a plurality of client-side subsystems, theoffline change data being generated at the client-side subsystems whenthe client-side subsystems are not connected to the back-end sub-systemover the communications network, wherein the offline change datarepresents changes that have not been synchronized with the back-endsystem, and wherein at least one of the entries reflects creation of anew base document, at least one of the entries reflects a change to thenew base document, and at least one of the entries reflects a change toa previously synchronized based document, wherein for the respectivesynchronization queues, the first entry is the earliest offline changedata and the last entry is the latest offline change data; andsynchronizing, by the back-end sub-system, the entries in thesynchronization queues until all such entries are processed, wherein thesynchronizing comprises: upon determining that the entry corresponds tocreation of a new base document, generating a new backend key associatedwith the new base document, mapping the new backend key to a client keygenerated at the corresponding client-side subsystem and associated withthe new base document to form a mapped key pair in a key mapping table,and storing change data specified by the entry in the back-endsub-system in association with the new backend key; upon determiningthat the entry corresponds to a change to the new base document,identifying, using the client key corresponding to the new basedocument, the new backend key generated during the synchronizing usingthe key mapping table, and storing change data specified by the entry inthe back-end sub-system in association with the new backend key, andupon determining that the entry corresponds to a change to a previouslysynchronized base document associated with a pre-existing backend keystoring change data specified by the entry in the backend sub-system inassociation with the pre-existing backend key.
 6. The system of claim 5,wherein the entries are sequentially processed.
 7. The system of claim6, wherein the entries are processed on a first in first out (FIFO)basis.
 8. The system of claim 5, wherein the synchronization queues havex number of entries for generating x number of change data while offlinewithout synchronizing with the backend sub-system, and wherein the xnumber of entries being stored in the synchronization queue is based ona time when the change data is generated.
 9. Non-transitorycomputer-readable media storing instructions which, when executed by atleast one computer, result in operations comprising: receiving, by aninbound queue at a back-end sub-system over a communications network,offline change data originating as entries in synchronization queues ona plurality of client-side subsystems, the offline change data beinggenerated at the client-side subsystems when the client-side subsystemsare not connected to the back-end sub-system over the communicationsnetwork, wherein the offline change data represents changes that havenot been synchronized with the back-end system, and wherein at least oneof the entries reflects creation of a new base document, at least one ofthe entries reflects a change to the new base document, and at least oneof the entries reflects a change to a previously synchronized baseddocument, wherein for the respective synchronization queues, the firstentry is the earliest offline change data and the last entry is thelatest offline change data; and synchronizing, by the back-endsub-system, the entries in the synchronization queues until all suchentries are processed, wherein the synchronizing comprises: upondetermining that the entry corresponds to creation of a new basedocument, generating a new backend key associated with the new basedocument, mapping the new backend key to a client key generated at thecorresponding client-side subsystem and associated with the new basedocument to form a mapped key pair in a key mapping table, and storingchange data specified by the entry in the back-end sub-system inassociation with the new backend key; upon determining that the entrycorresponds to a change to the new base document, identifying, using theclient key corresponding to the new base document, the new backend keygenerated during the synchronizing using the key mapping table, andstoring change data specified by the entry in the back-end sub-system inassociation with the new backend key, and upon determining that theentry corresponds to a change to a previously synchronized base documentassociated with a pre-existing backend key storing change data specifiedby the entry in the backend sub-system in association with thepre-existing backend key.
 10. The computer-readable media of claim 9,wherein the entries are sequentially processed.
 11. Thecomputer-readable media of claim 10, wherein the entries are processedon a first in first out (FIFO) basis.
 12. The computer-readable media ofclaim 9, wherein the synchronization queues have x number of entries forgenerating x number of change data while offline without synchronizingwith the backend sub-system, and wherein the x number of entries beingstored in the synchronization queue is based on a time when the changedata is generated.